For increased transmission bandwidth and reliability, a local host computer in a data processing network often has a plurality of outbound source paths for transmitting data to a remote host computer in the data network. Each outbound source path may include a selected network interface device of the local host, and a selected gateway connecting the local host computer to the data network.
A conventional practice has been for the network layer of the operating system of a local host to select for a host application a particular one of a number of possible outbound source paths in a fashion that is transparent to the host application. For example, the host application calls an application program interface (API) function of a network layer program in order to establish a connection to a destination address of a remote host, and upon receiving confirmation from the API function that a connection has been established, the host application writes data to a socket for the connection. The operating system then routes packets of the data from the socket to the destination address of the remote host depending on the availability of the possible paths and often depending on loading conditions of the possible paths.
In an Internet-Protocol (IP) data network, selection of data paths between a host and the Internet occurs for a so-called “multi-homed host” having more than one IP address, and for a host at a so-called “multi-homed site” having more than one IP service provider.
Multi-homed Internet hosts are discussed in G. Houston, Architectural Approaches to Multi-homing for IPv6, Network Working Group Request for Comments: 4177, September 2005, The Internet Society. The environment of multi-homing is intended to provide sufficient support to local hosts so as to allow local hosts to exchange IP packets with remote hosts, such that this exchange of packets is transparently supported across dynamic changes in connectivity. Session resilience implies that if a local multi-homed-aware host establishes an application session with the remote host using “Path A”, and this path fails, the application session should be mapped across to “Path B” without requiring any application-visible re-establishment of the session. In other words, the application session should not be required to be explicitly aware of underlying path changes at the level of packet forwarding paths chosen by the network. Established sessions should survive dynamic changes in network-level reachability.
Multi-homed Internet sites are discussed in J. Abley et al., Goals for IPv6 Site-Multihoming Architectures, Network Working Group Request for Comments: 3582, August 2003, The Internet Society. By multihoming, a site should be able to insulate itself from certain failure modes within one or more transit providers, as well as failures in the network providing interconnection among one or more transit providers. By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. This goal is for concurrent use of the multiple transit providers, not just the usage of one provider over one interval of time and another provider over a different interval.